\section{Development}

\subsection{Server}
The component server manages orders of clients, orders could arrive at every time, so it must be setted up for receiving asynchronous requests. 
The server is principally a class with a main thread which initializes the connection and listens for clients. Sequence diagram \ref{fig:ssd} shows
 all the main activities of server; we could see in particular a scenario where two client want to communicate an order to the server at the same 
time (server must manage most clients at the same time).

Let's see \ref{fig:ssd}.

The client on the left contacts the server, after its initialization it listens continuously to port 4444 by default. 
A new thread called \texttt{ClientCustomer} will be created, one for each client, it sends the menu, builded istantly in order to a correct 
representation of items availability.

Almost at the same time the client on the rigth requests a new connection with the server, so a new thread \texttt{CustomerClient} will be 
created and a new menu will be sent. In the meanwhile the client on the left is choosing its ordination, when \texttt{ClientCustomer} will receive 
the ordination it will receive a \texttt{Vector} of items and every countable item (therefore we will exclude, for example, drinks) will have a 
\texttt{quantity} attribute associated.

We could see that the first ordination of client on the left contains some error, maybe concerning one or more item quantity excess, in this case 
\texttt{CustomerServer} thread will send to client all items that exceed the quantity available, subsequently client can either prepare another 
order or shut down the communication. The second order of left client is correct, so \texttt{CustomerServer} approximately calculate the time 
necessary to prepare the ordination and send it to client, in the meanwhile the client on the right sends another order to its 
\texttt{CustomerServer} and receive its time to wait.

When the order is really ready to be picked up an asynchronous message from \texttt{CustomerClient} to its client will be sent, and the 
communication could be closed. The same one is for {Client} on the right.

In case that a client wants to close communication without send any order server must neatly manage the event, a clean interruption of 
communication could be done with a good exception management. A communication breakdown could happen, for example, while client is waiting for 
receive a message for pick up his order, in this case \texttt{ClientCustomer} will terminate and consequently will not send any following message. 
Every communication interrupted by the user is lost forever, without any kind of connection re-enstablishing.


\begin{figure}
\centering

 \includegraphics[width=0.5\textwidth]{img/SequenceDiagram.png}\caption{Server main sequence diagram}
 % SequenceDiagram.png: 746x529 pixel, 72dpi, 26.31x18.66 cm, bb=0 0 746 529
\label{fig:ssd}
\end{figure}

\subsection{Client}

\subsubsection{Logical View}
The component \texttt{LogicalView} manages the forward of the orders to the server. The first thing to done is connect to the server and retreive 
the menu (the menu is the first thing sended by the server after the connection), at this point the user can do an order selecting the items that 
he wants with the relative quantity. When and order is sended a thread is started to listen messages sended by the server, in particular the one 
that say when an order can be retrieved.

Starting a new thread is essentialy to not freeze the application to wait the messages. The LogicalView can archive all messages sended by the 
server and the GUI can read them asynchronously, more precisly it can read the last message received or all the still unreaded messages.

Order management is simple, every item has an unique integer id associated and the id of every item that the user wants to order is 
encapsulated in an object \texttt{Order} with the respective quantity. When the user wants to order an item selecting it by the GUI, a method is 
called, this method checks if the same item was already inserted in the \texttt{Order}, in these case it increments the quantity of that item, in 
the other case it inserts the new item in the order with quantity 1. Obviusly there is a complementary method that decrement the quantity of an 
item in an \texttt{Order} and when the quantity becomes 0 it is removed.

When the user has selected all the items that he want to order, he call a method (because the order is still only on the client), alway using 
the GUI, that sends the order to the server and starts the thread for incoming messages mentioned above.

The messages are archived in a \texttt{Vector} that didn't contain only an array of \texttt{String} that are the body of the message, but for each message there is 
a boolean attribute that is used to know if the message was already readed by the GUI on not. In these way is possibile for the GUI request to 
read all the unreaded messages. The other possibility is to read only the last message. There is a particular message that is not archived and it is
 sended by the server when it wants to close the connection. Reading and saving of a message are synchronized, so is impossible read a message 
while it isn't completely saved.

\subsubsection{Layout}
The GUI of the application wants to be as simple as possible to permit a comfortable use of it by the user. Of course it communicates with the logical implementation of the 
client by using available methods.

It's composed by two Activities, an \and 's \texttt{Activity} is a window when the developer can place an User Interface (UI) with any widget included
into the \and \texttt{SDK}. 

The first \texttt{Activity} launched by the application is the \texttt{MainActivity}.

Its graphical structure is very simple, with a welcome message in a \texttt{TextView} and a \texttt{Menu} selectable from the Menu button on the mobile. By 
clicking the unique menu item (\emph{``Connect''}) the application will connect to the server and, when the connection is estabilished, the second \texttt{Activity} starts.

\texttt{MenuViewActivity} is the principal \texttt{Activity} of the application. It contains all the widgets and the graphical components that allow an user to perform 
all actions permitted by a client. So in this \texttt{Activity} an user can:
\begin{itemize}
 \item read the menu
 \item obtain information about the menu items
 \item define a quantity of a menu item to order
 \item send the order
 \item exit the application
\end{itemize}

A menu is represents by an \texttt{ExpandableListView} Object (a view that shows items in a vertically scrolling two-level list) due to menu items are collected 
into categories, so each category (groups) can be expanded to a list of items (children), to look for a menu item, and collapsed too. 

The access to the data of the children, categorized by groups, on the \texttt{ExpandableListView} is manage by an \texttt{ExpandableListAdapter} Object, that 
also instantiates \texttt{View}s for children and groups.

Each children (menu item) contains the name of the item, its price and the current quantity selected for it.

By long pressing on a menu item a \texttt{ContextMenu} is open and by it an user can:
\begin{itemize}
 \item increment or decrement the quantity to order
 \item read a more exaustive description of the item
\end{itemize}

By clicking the Menu button on the mobile a \texttt{Menu} containing two items (\emph{``Send Order''} and \emph{``Exit''}) appears.

\emph{Send Order} continues the communication with the sever and send an order to it. When this \texttt{MenuItem} is clicked a \texttt{ProgressDialog} is shown 
and after it a \texttt{Dialog} with details as informative (and possible error) messages sending by the server during the evalutation of the order.

\emph{Exit} says goodbye to the user by a \texttt{Dialog} Object and terminates the two Activities.

While the mobile is exchanging messages with the server a \texttt{AsyncTask} starts in background and Dialogs are shown while it runs in background.

So in these situations the application don't stop attempting to receive some messages, but shows Dialogs to inform that 
a client-server communication is going due to the waiting-time for te user could be different, depending by some factors such as network traffic or 
state.


